CodeAgent CLI 项目深挖 · 单期模块。总览见 需求分析 与 整体设计方案。

LSP 诊断注入解决的是「Agent 写完代码不知道自己写错了」——write_file 之后立刻做语法诊断，把编译级错误作为观察喂回下一轮，让模型在再次思考前看到自己刚写出的坏代码，而不是等用户跑一次构建才发现。

诊断链路（write_file 后的钩子）

1. write_file 执行后触发 LspManager.runPostEditLspHook（带配置开关，关闭时零开销）；
2. 只处理 .java 文件：非 Java 或文件已删除 → 清空该文件的历史诊断，不误报；
3. diagnoseJava 用 JavaParser（Java 17 语法级）解析文件，产出 LspDiagnostic 列表（severity / line / message，行号下限 1）；
4. replaceDiagnostics 按文件覆盖 pending 缓存（LinkedHashMap 保持插入序）；
5. 下一轮 ReAct 循环里 injectPendingLspDiagnostics 把累计诊断经 LspDiagnosticFormatter 格式化成 user message 注入（上限 20 条），模型在下一次思考前就能看到编译错误。

为什么用 JavaParser，而不是接一个真正的 LSP server？

MVP 取舍。JavaParser 是进程内库：零进程开销、零版本兼容问题、诊断结果确定；真正的 LSP server（比如 Eclipse JDT LS）要起独立语言服务器进程、冷启动慢、配置和协议都重。当前产出的是语法级诊断——恰好覆盖「写出编译错误」这个最高频问题；语义级分析（类型推断、跨文件引用解析）是真 LSP 才能做的，这是明示的能力边界。

诊断为什么放 user message，而不是 system prompt 或工具结果？

和 Skill 注入是同一个道理——注入位置决定模型怎么理解这段文字。诊断是「这一轮产生的新观察」，放 user message 才跟得上轮次变化；放 system prompt 会污染缓存前缀。上限 20 条是防止连续写多个文件后，诊断文本淹没真正的任务上下文。

只支持 Java 吗？

当前 MVP 只对 .java 做诊断，这是 JavaParser 的能力边界；其他格式写完会把该文件的诊断清空而不是留着旧报告误导模型。扩展点就在 runPostEditLspHook 里，按扩展名分发到对应语言的诊断器即可。